…t custom key length restrictions.

Fixes #541

Closes #547

- moved all specific Public/Secret logic from the Adapter class into
  inner subclasses in the Fragments
- more versatile status display ("revoked", "expired", "can certify"...)
- applied view holder pattern
- query logic, including subqueries, moved into provider classes

Closes #375

Closes #551

It isn't a key capability like certify, encrypt, sign,
and it's redundant, since the key is crossed out.

This allows any KeyServer to store some extra data it might need.
In the case of KeybaseKeyServer it is the username, which then can
be grabbed directly, without the hack of storing it as userId.

Once keybase reports them, we can display them. Until then we simply
don't know and shouldn't lie about it.

Remove ctime and the cached key, making the query for the entire user
object unnecessary. This should only be done when the user decides to
import the key. Hopefully keybase.io can provide all info necessary in
the search results.

The very point of keybase.io is the identification and proven link
to those identities, so it should be nice to have them.
The display is a bit basic still, as it just adds them as userIds,
I'm sure this can be prettified, perhaps with logos?

For the regex matching it would be smart to sort the words by length,
so the longest matches come first. This only matters for queries with
words containing parts of each other, which is an unlikely event and
even then it doesn't break anything.